An object is a logically grouped set of computer-executable functions and computer-readable data. Objects are well-known to programmers of object-oriented languages such as C++, Ada, Smalltalk, PERL and Java. While the implementation details of objects varies from programming language to programming language, they all have certain characteristics in common. One such characteristic is known as “encapsulation.” Encapsulation means that an object performs its designated purpose in a manner that is hidden from the rest of the program in which it is being used. The hidden data and functions that an object uses to perform its purpose are collectively referred to as private data Outside entities, such as a main program or a function, may only access an object through its public functions and data. The set of public functions and data for an object is often referred to as a public interface or programming interface. An object may be written according to a variety of well-known standards, including the MICROSOFT COMPONENT OBJECT MODEL (COM), the MICROSOFT DISTRIBUTED COMPONENT OBJECT MODEL (DCOM), and the common object request broker architecture (CORBA). An object may also be compiled into machine code, assembly code, binary code, byte code, or the like, and may be executed on a computer as, for example, an executable file, a DLL, or the like.
One of the advantages of writing a program using an object-oriented language is that the program may be broken up into set of self-contained units or “objects.” Each object in an object-oriented program typically has a set of public functions and public data that can be accessed by other parts of the program, and a set of private functions and private data that are hidden from the rest of the program. Anything outside an object that wishes to use the object to perform some task must access the object using the public functions and data. How the object performs its task is hidden from the outside through the use of private functions and data. In effect, an object functions as a “black box” that can receive data, perform a task, and possibly return a result to a caller. Because the internal implementation details of an object are hidden, it is very convenient to create libraries of objects that can be used over and over in multiple programming projects. The public functions and data of an object are typically exposed as one or more interfaces. An interface generally contains pointers to classes that contain the public functions and data.
Frequently, libraries of objects are developed and sold along with programming packages to relieve programmers of the burden of creating their own objects from scratch. The objects in such libraries are generally provided as compiled binary files for the sake of convenience and to keep their internal implementation details confidential. As long as a programmer knows what a particular object is capable of doing, what public functions it exposes, and what inputs it requires, he or she does not have to know how the function is implemented, and may, in fact, create a program from a set of objects written by someone else.
Currently, debugging a program that uses objects often requires more than just a “black-box” knowledge of the objects. Specifically, it may require a programmer to s learn the internal structure of the objects and thereby violate the principle of encapsulation. It is frequently the case, however, that data contained in an object is not present in the memory to which the programmer has access, thus making it nearly impossible to learn its internal structure. For example, a DCOM object may have a proxy on one machine of a network while the bulk of its functions and data are located on another machine of the network and are only accessible by a stub. There are also cases in which a public interface pointer actually points to a thread-specific proxy and not to the real data, such as when the “apartment threading model” is used.